%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright by Olaf Kirch, okir@monad.swb.de   %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\def\elmlib{\file{/usr/lib/elm}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%        S T A R T   O F   C H A P T E R                        %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Electronic Mail}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail}
\index{electronic mail}
\index{mail}
\index{email|see {mail}}

One of the most prominent uses of networking since the first networks
were devised, has been eletronic mail.  It started as a simple service
that copied a file from one machine to another, and appended it to the
recipient's \emph{mailbox} file. Basically, this is still what email is
all about, although an ever growing net with its complex routing
requirements and its ever increasing load of messages has made a more
elaborate scheme necessary.


\index{multi-media mail}
\index{mail!multi-media}
Various standards of mail exchange have been devised. Sites on the
Internet adhere to one laid out in RFC~822, augmented by some RFCs that
describe a machine-independent way of transferring special characters,
and the like. Much thought has also been given recently to ``multi-media
mail'', which deals with including pictures and sound in mail messages.
Another standard, X.400, has been defined by CCITT.


\index{sendmail@\prog{sendmail}}
\index{Allman, Eric}
Quite a number of mail transport programs have been implemented for
\unix{} systems. One of the best-known is the University of Berkeley's
\prog{sendmail}, which is used on a number of platforms. The original
author was Eric Allman, who is now actively working on the
\prog{sendmail} team again.  There are two \linux{} ports of
\prog{sendmail-5.56c} available, one of which will be described in
chapter~\ref{sendmail}. The \prog{sendmail} version currently being
developed is~8.6.5.


\index{smail@\prog{smail}}
\index{Karr, Ronald S.}
\index{Noll, Curt Landon}
The mail agent most commonly used with \linux{} is \prog{smail-3.1.28},
written and copyrighted by Curt Landon Noll and Ronald S.~Karr. This is the
one included in most \linux{} distributions.  In the following, we will
refer to it simply as \prog{smail}, although there are other versions of it
which are entirely different, and which we don't describe here.


Compared to \prog{sendmail}, \prog{smail} is rather young. When handling
mail for a small site without complicated routing requirements, their
capabilities are pretty close. For large sites, however, \prog{sendmail}
always wins, because its configuration scheme is much more flexible.


Both \prog{smail} and \prog{sendmail} support a set of configuration
files that have to be customized. Apart from the information that is
required to make the mail subsystem run (such as the local hostname),
there are many more parameters that may be tuned.  \prog{sendmail}'s
main configuration file is very hard to understand at first. It looks as
if your cat had taken a nap on your keyboard with the shift key pressed.
\prog{smail} configuration files are more structured and easier to
understand than \prog{sendmail}'s, but don't give the user as much power
in tuning the mailer's behavior.  However, for small UUCP or Internet
sites the work required in setting up any of them is roughly the same.


In this chapter, we will deal with what email is and what issues you as
an administrator will have to deal with.  Chapters~\ref{smail}
and~\ref{sendmail} will give instructions on setting up \prog{smail} and
\prog{sendmail} for the first time.  The information provided there
should suffice to get smaller sites operational, but there are many more
options, and you can spend many happy hours in front of your computer
configuring the fanciest features.


Toward the end of the current chapter we will briefly cover setting up
\prog{elm}, a very common mail user agent on many \unix{}ish systems,
including \linux{}.


For more information about issues specific to electronic mail on
\linux, please refer to the Electronic Mail HOWTO by Vince Skahan,
which is posted to \ngrp{comp.os.linux.announce} regularly.  The
source distributions of \prog{elm}, \prog{smail} and \prog{sendmail}
also contain very extensive documentation that should answer most of
your questions on setting them up.  If you are looking for information
on email in general, there's a number of RFCs that deal with this
topic. They are listed in the bibliography at the end of the book.


\section{What is a Mail Message?}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Brief intro to messages and headers. Mentions RFC 822.        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.message-format}
\index{mail!message format}
\index{mail!headers}

A Mail message generally consists of a message body, which is the text
the sender wrote, and special data specifying recipients, transport
medium, etc., very much like what you see when you look at a letter's
envelope.


This administrative data falls into two categories; in the first
category is any data that is specific to the transport medium, like
the address of sender and recipient. It is therefore called \emph{the
envelope}.  It may be transformed by the transport software as the
message is passed along.


The second variety is any data necessary for handling the mail message,
which is not particular to any transport mechanism, such as the
message's subject line, a list of all recipients, and the date the
message was sent.  In many networks, it has become standard to prepend
this data to the mail message, forming the so-called \emph{mail header}.
It is offset from the \emph{mail body} by an empty line.\footnote{
 It is customary to append a \emph{signature} or \file{.sig} to a mail
 message, usually containing information on the author, along with a
 joke or a motto. It is offset from the mail message by a line
 containing ``\term{-- }''.
 %%% Maybe \verb*|-- | would be better?
}


Most mail transport software in the \unix{} world uses a header format
outlined in a RFC~822.  Its original purpose was to specify a standard
for use on the ARPANET, but since it was designed to be independent from
any environment, it has been easily adapted to other networks, including
many UUCP-based networks.


RFC~822 however is only the greatest common denominator. More recent
standards have been conceived to cope with growing needs as, for
example, data encryption, international character set support, and
multi-media mail extensions (MIME).


In all these standards, the header consists of several lines, separated
by newline characters. A line is made up of a field name, beginning in
column one, and the field itself, offset by a colon and white space. The
format and semantics of each field vary depending on the field name. A
header field may be continued across a newline, if the next line begins
with a TAB.  Fields can appear in any order.


A typical mail header may look like this:


\noindent
\begin{tscreen}
\begin{verbatim}
From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994
Return-Path: <brewhq.swb.de!ora.com!andyo>
Received: from brewhq.swb.de by monad.swb.de with uucp
        (Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST
Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp
        (Smail3.1.28.1 #28.6) id <m0pqoQr-0008qhC>; Tue, 12 Apr 94 21:47 MEST
Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 15:56 -0400
Date: Tue, 12 Apr 1994 15:56:49 -0400
Message-Id: <199404121956.PAA07787@ruby>
From: andyo@ora.com (Andy Oram)
To: okir@monad.swb.de
Subject: Re: Your RPC section
\end{verbatim}
\end{tscreen}


Usually, all necessary header fields are generated by the mailer
interface you use, like \prog{elm}, \prog{pine}, \prog{mush}, or
\prog{mailx}. Some however are optional, and may be added by the user.
\prog{elm}, for example, allows you to edit part of the message header.
Others are added by the mail transport software. A list of common
header fields and their meaning are given below:


\begin{dispitems}
\ditem[\mhdr{From:}]
        This contains the sender's email address, and possibly the
        ``real name''. A complete zoo of formats is used here.

\ditem[\mhdr{To:}]
        This is the recipient's email address. 

\ditem[\mhdr{Subject:}]
        Describes the content of the mail in a few words. At least
        that's what it \emph{should} do.

\ditem[\mhdr{Date:}] 
        The date the mail was sent.

\ditem[\mhdr{Reply-To:}]
        Specifies the address the sender wants the recipient's reply
        directed to. This may be useful if you have several accounts,
        but want to receive the bulk of mail only on the one you use
        most frequently. This field is optional.

\ditem[\mhdr{Organization:}]
        The organization that owns the machine from which the mail
        originates. If your machine is owned by you privately, either
        leave this out, or insert ``private'' or some complete nonsense.
        This field is optional.

\ditem[\mhdr{Message-ID:}]
        A string generated by mail transport on the originating system.
        It is unique to this message.

\ditem[\mhdr{Received:}]
        Every site that processes your mail (including the machines
        of sender and recipient) inserts such a field into the header,
        giving its site name, a message id, time and date it received
        the message, which site it is from, and which transport software
        was used. This is so that you can trace which route the message
        took, and can complain to the person responsible if something
        went wrong.

\ditem[\mhdr{X-\sl anything:}]
        No mail-related programs should complain about any header which
        starts with \mhdr{X-}. It is used to implement additional
        features that have not yet made it into an RFC, or never will.
        This is used by the Linux Activists mailing list, for example,
        where the channel is selected by the \mhdr{X-Mn-Key:} header
        field.

\end{dispitems}


The one exception to this structure is the very first line. It starts
with the keyword \mhdr{From} which is followed by a blank instead of a
colon.  To distinguish it from the ordinary \mhdr{From:} field, it is
frequently referred to as \mhdr{From\_}.  It contains the route the
message has taken in UUCP bang-path style (explained below), time and
date when it was received by the last machine having processed it, and
an optional part specifying which host it was received from. Since this
field is regenerated by every system that processes the message, it is
somtimes subsumed under the envelope data.


The \mhdr{From\_} field is there for backward compatibilty with some
older mailers, but is not used very much anymore, except by
mail user interfaces that rely on it to mark the beginning of a
message in the user's mailbox. To avoid potential trouble with lines
in the message body that begin with ``From '', too, it has become
standard procedure to escape any such occurence by preceding it with
``$>$''.



\section{How is Mail Delivered?}
\label{mail.delivery}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Mail transport and Delivery.                                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{mail!composing}
\index{composing mail}
\index{mail!delivering|(}
\index{delivering!mail|(}
\index{exchanging!mail|(}
\index{lmail@\prog{lmail}}
\index{rmail@\prog{rmail}}

Generally, you will compose mail using a mailer interface like \prog{mail}
or \prog{mailx}; or more sophisticated ones like \prog{elm}, \prog{mush},
or \prog{pine}. These programs are called \emph{mail user agents}, or MUA's
for short. If you send a mail message, the interface program will in most
cases hand it to another program for delivery. This is called the
\emph{mail transport agent}, or MTA. On some systems, there are different
mail transport agents for local and remote delivery; on others, there is
only one.  The command for remote delivery is usually called \prog{rmail},
the other is called \prog{lmail} (if it exists).


\index{mail!bounce}
\index{bounce mail}
Local delivery of mail is, of course, more than just appending the
incoming message to the recipient's mailxbox. Usually, the local MTA
will understand aliasing (setting up local recipient addresses pointing
to other addresses), and forwarding (redirecting a user's mail to some
other destination). Also, messages that cannot be delivered must usually
be \emph{bounced}, that is, returned to the sender along with some
error message.


\index{Simple Mail Transfer Protocol|see {SMTP}}
\index{SMTP}
For remote delivery, the transport software used depends on the nature
of the link.  If the mail must be delivered over a network using TCP/IP,
SMTP is commonly used.  SMTP stands for Simple Mail Transfer Protocol,
and is defined in RFC~788 and RFC~821.  SMTP usually connects to the
recipient's machine directly, negotiating the message transfer with the
remote side's SMTP daemon.


\index{remote!execution}
\index{UUCP!mail}
\index{mail!over UUCP}
In UUCP networks, mail will usually not be delivered directly, but
rather be forwarded to the destination host by a number of intermediate
systems. To send a message over a UUCP link, the sending MTA will
usually execute \prog{rmail} on the forwarding system using \prog{uux},
and feed it the message on standard input.


\index{BSMTP}
\index{SMTP!batched}
\index{mail!batching}
\index{batching!mail}
\index{rsmtp@\prog{rsmtp}}
Since this is done for each message separately, it may produce a
considerable work load on a major mail hub, as well as clutter the UUCP
spool queues with hundreds of small files taking up an unproportional
amount of disk space.\footnote{
  This is because disk space is usually allocated in blocks of 1024 Bytes.
  So even a message of at most 400 Bytes will eat a full KB.
} Some MTAs therefore allow you to collect several messages for a remote
system in a single batch file. The batch file contains the SMTP commands
that the local host would normally issue if a direct SMTP connection was
used.  This is called BSMTP, or \emph{batched} SMTP. The batch is then
fed to the \prog{rsmtp} or \prog{bsmtp} program on the remote system,
which will process the input as if a normal SMTP connection had
occurred.

\index{mail!delivering|)}
\index{exchanging!mail|)}
\index{delivering!mail|)}


\section{Email Addresses}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Gives an introduction to Addresses. Could also be used in a   %
% Section on Using mail.                                        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.address}
\index{mail!address formats|(}
\index{address!mail|(}

For electronic mail, an address is made up of at least the name of a
machine handling the person's mail, and a user identification recognized
by this system. This may be the recipient's login name, but may also be
anything else. Other mail addressing schemes, like X.400, use a more
general set of ``attributes'' which are used to look up the recipient's
host in an X.500 directory server.


The way a machine name is interpreted, i.e. at which site your message
will finally wind up, and how to combine this name with the recipient's
user name greatly depends on the network you are on.


Internet sites adhere to the RFC~822 standard, which requires a notation
of \host{user@host.domain}, where \host{host.domain} is the host's fully
qualified domain name. The middle thing is called an ``at'' sign.
Because this notation does not involve a route to the destination host
but gives the (unique) hostname instead, this is called an \emph{absolute}
address.


\index{mail!bang path address}
\index{address!bang path}
In the original UUCP environment, the prevalent form was
\host{path!host!user}, where \host{path} described a sequence of hosts
the message had to travel before reaching the destination \host{host}.
This construct is called the \emph{bang path} notation, because an
exclamation mark is loosely called a ``bang''.  Today, many UUCP-based
networks have adopted RFC~822, and will understand this type of
address.


\index{address!hybrid}
Now, these two types of addressing don't mix too well. Assume an address
of \email{hostA!user@hostB}. It is not clear whether the `\email{@}' sign
takes precedence over the path, or vice versa: do we have to send the
message to \host{hostB}, which mails it to \host{hostA!user}, or should it
be sent to \host{hostA}, which fowards it to \email{user@hostB}?


Addresses that mix different types of address operators are called
\emph{hybrid addresses}. Most notorious is the above example. It is
usually resolved by giving the `\email{@}' sign precedence over the
path. In the above example, this means sending the message to
\host{hostB} first.


% Those awkward $>$ and $<$ are there to protect the > from LaTeX... yuk!
% This will only look okay with LaTeX2e, I fear.
\index{address!route-addr}
\index{mail!route-addr address}
However, there is a way to specify routes in RFC~822-conformant ways:
\email{$<$@hostA,@hostB:user@hostC$>$} denotes the address of \email{user} on
\host{hostC}, where \host{hostC} is to be reached through \host{hostA}
and \host{hostB} (in that order). This type of address is freqeuently
called a \emph{route-addr address}.


\index{Ye Olde ARPANET kludge}
Then, there is the `\email{\%}' address operator: \email{user\%hostB@hostA}
will first be sent to \host{hostA}, which expands the rightmost (in this
case, only) percent sign to an `\email{@}' sign. The address is now
\user{user@hostB}, and the mailer will happily forward your message to
\host{hostB} which delivers it to \email{user}.  This type of address is
sometimes referred to as ``Ye Olde ARPANET Kludge'', and its use is
discouraged. Nevertheless, many mail transport agents generate this
type of address.

% It was used on the ARPANET to reach hosts who were not registered
% officially with the Network Information Center, so that messages had to
% be sent via a mail relay that was known to handle mail for these
% ``hidden'' sites.


Other networks have still different means of addressing. DECnet-based
networks, for example, use two colons as an address separator, yielding
an address of \var{host}\email{::}\var{user}.\footnote{
 When trying to reach a DECnet address from an RFC~822 environment, you
 may use \email{"\var{host}::\var{user}"@\var{relay}}, where \var{relay}
 is the name of a known Internet-DECnet relay.
} Lastly, the X.400 standard uses an entirely different scheme, by
describing a recipient by a set of attribute-value pairs, like country
and organization.  


On FidoNet, each user is identified by a code like \host{2:320/204.9},
consisting of four numbers denoting zone (2 is for Europe), net (320
being Paris and Banlieue), node (the local hub), and point (the
individual user's PC). Fidonet addresses can be mapped to RFC~822; the
above would be written as
\email{Thomas.Quinot@p9.f204.n320.z2.fidonet.org}. Now didn't I say
domain names are easy to remember?


There are some implications to using these different types of addressing
which will be described throughout the following sections. In a RFC~822
environment, however, you will rarely use anything else than absolute
addresses like \email{\var{user}@\var{host}.\var{domain}}.

\index{mail!address formats|)}
\index{address!mail|)}

\section{How does Mail Routing Work?}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Extension to the above chapter on addresses.                  %
% Short introduction to maps, pathalias, and name servers.      %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.routing}
\index{mail!routing|(}
\index{routing!mail|see {mail routing}}

The process of directing a message to the recipient's host is called
\emph{routing}. Apart from finding a path from the sending site to the
destination, it involves error checking as well as speed and cost
optimization.


There is a big difference between the way a UUCP site handles routing,
and the way an Internet site does. On the Internet, the main job of
directing data to the recipient host (once it is known by it's
IP~address) is done by the IP networking layer, while in the UUCP zone,
the route has to be supplied by the user, or generated by the mail
transfer agent.


\subsection{Mail Routing on the Internet}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{mail.routing.internet}{Mail Routing on the Internet}
\index{mail!routing!Internet}
\index{mail!domain-based routing}
\index{mail!centralizing}
\index{centralized mail handling}
\index{Internet!mail routing}
\index{Mail Exchanger (DNS record)}
\index{MX (DNS record)}
\index{mail!gateway}
\index{gateway!mail}

On the Internet, it depends entirely on the destination host whether any
specific mail routing is performed at all. The default is to deliver the
message to the destination host directly by looking up its IP address,
and leave the actual routing of the data to the IP transport layer.


\index{mail!routing!between Internet and UUCP}
Most sites will usually want to direct all inbound mail to a highly
available mail server that is capable of handling all this traffic, and
have it distribute this mail locally. To announce this service, the site
publishes a so-called MX record for their local domain in the DNS
database.  MX stands for \emph{Mail Exchanger} and basically states
that the server host is willing to act as a mail forwarder for all
machines in this domain.  MX records may also be used to handle traffic
for hosts that are not connected to the Internet themselves, like UUCP
networks, or company networks with hosts carrying confidential
information.


MX records also have a \emph{preference} associated with them.  This is
a positive integer. If several mail exchangers exist for one host, the
mail transport agent will try to transfer the message to the exchanger
with the lowest preference value, and only if this fails will it try a
host with a higher value. If the local host is itself a mail exchanger
for the destination address, it must not forward messages to any MX
hosts with a higher preference than its own; this is a safe way of
avoiding mail loops.


Suppose that an organization, say Foobar Inc., want all their mail
handled by their machine called \host{mailhub}.  They will then have an
MX record like this in the DNS database:


\begin{tscreen}
\begin{verbatim}
foobar.com        IN   MX      5    mailhub.foobar.com
\end{verbatim}
\end{tscreen}


This announces \host{mailhub.foobar.com} as a mail exchanger for
\host{foobar.com} with a preference value of 5. A host that wishes to
deliver a message to \email{joe@greenhouse.foobar.com} will check DNS for
\host{foobar.com}, and finds the MX record pointing at \host{mailhub}.
If there's no MX with a preference smaller than 5, the message will be
delivered to \host{mailhub}, which then dispatches it to
\host{greenhouse}.


The above is really only a sketch of how MX records work.  For more
information on the mail routing on the Internet, please refer to
RFC~974.


\subsection{Mail Routing in the UUCP World}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.routing.uucp}
\index{mail!routing!UUCP networks}
\index{mail!bang path address}
\index{address!bang path}
\index{UUCP!mail}

Mail routing on UUCP networks is much more complicated than on the
Internet, because the transport software does not perform any routing
itself.  In earlier times, all mail had to be addressed using bang paths.
Bang paths specified a list of hosts through which to forward the
message, separated by exclamation marks, and followed by the user's
name.  To address a letter to Janet User on a machine named \host{moria},
you would have used the path \email{eek!swim!moria!janet}. Whis would
have sent the mail from your host to \host{eek}, from there on to
\host{swim} and finally to \host{moria}.


The obvious drawback of this technique is that it requires you to
remember much about the network topology, fast links, etc.  Much worse
than that, changes in the network topology~--- like links being deleted
or hosts being removed~--- may cause messages to fail simply because you
weren't aware of the change. And finally, in case you move to a
different place, you will most likely have to update all these routes.


\index{hostname!ambiguous}
One thing, however, that made the use of source routing necessary was
the presence of ambiguous hostnames: For instance, assume there are two
sites named \host{moria}, one in the U.S., and one in France. Which site
now does \email{moria!janet} refer to? This can be made clear by
specifying what path to reach \host{moria} through.


\index{UUCP!Mapping Project}
\index{mail!maps}
\index{Usenet!maps}
\index{maps, Usenet}
The first step in disambiguating hostnames was the founding of
\emph{The UUCP Mapping Project}. It is located at Rutgers University, and
registers all official UUCP hostnames, along with information on their
UUCP neighbors and their geographic location, making sure no hostname is
used twice. The information gathered by the Mapping Project is published
as the \emph{Usenet Maps}, which are distributed regularly through
Usenet.\footnote{
 Maps for sites registered with The UUCP Mapping Project are distributed
 through the newsgroup \ngrp{comp.mail.maps}; other organizations may
 publish separate maps for their network.
} A typical system entry in a Map (after removing the comments) looks
like this.


\begin{tscreen}
\begin{verbatim}
moria
        bert(DAILY/2),
        swim(WEEKLY)
\end{verbatim}
\end{tscreen}

This entry says that \host{moria} has a link to \host{bert}, which it
calls twice a day, and \host{swim}, which it calls weekly. We will
come back to the Map file format in more detail below.


\index{mail!paths file@\file{paths} file}
\index{pathalias@\prog{pathalias}}
\index{paths file@\file{paths} file}
Using the connectivity information provided in the maps, you can
automatically generate the full paths from your host to any destination
site. This information is usually stored in the \file{paths} file,
also called \emph{pathalias database} sometimes.  Assume the Maps
state that you can reach \host{bert} through \host{ernie}, then a
pathalias entry for \host{moria} generated from the Map snippet above
may look like this:


\begin{tscreen}
\begin{verbatim}
moria           ernie!bert!moria!%s
\end{verbatim}
\end{tscreen}


If you now give a destination address of \email{janet@moria.uucp},
your MTA will pick the route shown above, and send the message to
\host{ernie} with an envelope address of \email{bert!moria!janet}.


\index{mail!routing!smart-host}
\index{mail!default route}
\index{default mail route}
\index{smart-host routing}
\index{routing!smart-host}
\index{leaf site}
\index{site!leaf}
Building a \file{paths} file from the full Usenet maps is however not
a very good idea. The information provided in them is usually rather
distorted, and occasionally out of date.  Therefore, only a number of
major hosts use the complete UUCP world maps to build their
\file{paths} file.  Most sites only maintain routing information for
sites in their neighborhood, and send any mail to sites they don't
find in their databases to a smarter host with more complete routing
information. This scheme is called \emph{smart-host routing}.  Hosts
that have only one UUCP mail link (so-called \emph{leaf sites}) don't
do any routing of their own; they rely entirely on their smart-host.


\subsection{Mixing UUCP and RFC~822}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Relaying between UUCP and RFC 822				%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{mail!centralizing}
\index{centralized mail handling}
\index{mail!routing!domain-based}
\index{domain!mail routing}
The best cure against the problems of mail routing in UUCP networks so
far is the adoption of the domain name system in UUCP networks. Of
course, you can't query a name server over UUCP. Nevertheless, many
UUCP sites have formed small domains that coordinate their routing
internally. In the Maps, these domains announce one or two host as
their mail gateways, so that there doesn't have to be a map entry for
each host in the domain. The gateways handle all mail that flows into
and out of the domain. The routing scheme inside the domain is completely
invisible to the outside world.


This works very well with the smart-host routing scheme described
above.  Global routing information is maintained by the gateways only;
minor hosts within a domain will get along with only a small
hand-written \file{paths} file that lists the routes inside their
domain, and the route to the mail hub.  Even the mail gateways
do not have to have routing information for every single UUCP host in
the world anymore.  Beside the complete routing information for the
domain they serve, they only need to have routes to entire domains in
their databases now. For instance, the pathalias entry shown below
will route all mail for sites in the \host{sub.org} domain to
\host{smurf}:


\begin{tscreen}
\begin{verbatim}
.sub.org        swim!smurf!%s
\end{verbatim}
\end{tscreen}


Any mail addressed to \email{claire@jones.sub.org} will be sent to
\host{swim} with an envelope address of \email{smurf!jones!claire}.


The hierarchical organization of the domain name space allows mail
servers to mix more specific routes with less specific ones. For
instance, a system in France may have specific routes for subdomains
of \host{fr}, but route any mail for hosts in the \host{us} domain
toward some system in the U.S.  In this way, domain-based routing (as
this technique is called) greatly reduces the size of routing datbases
as well as te administrative overhead needed.


The main benefit of using domain names in a UUCP environment, however,
is that compliance with RFC~822 permits easy gatewaying between UUCP
networks and the Internet.  Many UUCP domains nowadays have a link
with an Internet gateway that acts as their smart-host.  Sending
messages across the Internet is faster, and routing information is
much more reliable because Internet hosts can use DNS instead of the
Usenet Maps.


In order to be reachable from the Internet, UUCP-based domains usually
have their Internet gateway announce an MX record for them (MX records
were described above). For instance, assume that \host{moria} belongs
to the \host{orcnet.org} domain.  \host{gcc2.groucho.edu} acts as
their Internet gateway. \host{moria} would therefore use \host{gcc2}
as its smart-host, so that all mail for foreign domains is delivered
across the Internet.  On the other hand, \host{gcc2} would announce an
MX record for \host{orcnet.org}, and deliver all incoming mail for
\host{orcnet} sites to \host{moria}.


The only remaining problem is that the UUCP transport programs can't
deal with fully qualified domain names.  Most UUCP suites were
designed to cope with site names of up to eight characters, some even
less, and using non-alphanumeric characters such as dots is completely
out of the question for most.


Therefore, some mapping between RFC~822 names and UUCP hostnames is
needed.  The way this mapping is done is completely
implementation-dependent. One common way of mapping FQDNs to UUCP
names is to use the pathalias file for this:


\begin{tscreen}
\begin{verbatim}
moria.orcnet.org  ernie!bert!moria!%s
\end{verbatim}
\end{tscreen}


This will produce a pure UUCP-style bang path from an address that
specifies a fully qualified domain name. Some mailers provide a
special files for this; \prog{sendmail}, for instance, uses the
\file{uucpxtable} for this.


The reverse transformation (colloquially called domainizing)  is
sometimes required when sending mail from a UUCP network to the
Internet.  As long as the mail sender uses the fully qualified domain
name in the destination address, this problem can be avoided by not
removing the domain name from the envelope address when forwarding the
message to the smart-host. However, there are still some UUCP sites
that are not part of any domain.  They are usually domainized by
appending the pseudo-domain \host{uucp}.


\index{mail!routing|)}


\section{Pathalias and Map File Format}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Map files                                                     %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.pathalias} \label{mail.maps}
\index{mail!paths file@\file{paths} file|(}
\index{paths file@\file{paths} file|(}
\index{generating a paths file@generating a \file{paths} file}

The pathalias database provides the main routing information in
UUCP-based networks. A typical entry looks like this (site name
and path are separated by TABs):


\begin{tscreen}
\begin{verbatim}
moria.orcnet.org  ernie!bert!moria!%s
moria             ernie!bert!moria!%s
\end{verbatim}
\end{tscreen}


This makes any message to \host{moria} be delivered via \host{ernie}
and \host{bert}. Both \host{moria}'s fully qualified name and its UUCP
name have to be given if the mailer does not have a separate way to
map between these name spaces.


\index{mail!centralizing}
\index{centralized mail handling}
\index{mail!domain-based routing}
If you want to direct all messages to hosts inside some domain to its
mail relay, you may also specify a path in the pathalias database,
giving the domain name as target, preceded by a dot. For example, if
all hosts in the \host{sub.org} may be reached through
\host{swim!smurf}, the pathalias entry might look like this:


\begin{tscreen}
\begin{verbatim}
.sub.org        swim!smurf!%s
\end{verbatim}
\end{tscreen}


Writing a pathalias file is acceptable only when you are running a site
that does not have to do much routing.  If you have to do routing for a
large number of hosts, a better way is to use the \prog{pathalias} command
to create the file from map files.  Maps can be maintained much easier,
because you may simply add or remove a system by editing the system's map
entry, and re-create the map file.  Although the maps published by the
Usenet Mapping Project aren't used for routing very much anymore, smaller
UUCP networks may provide routing information in their own set of maps.


\index{mail!maps}
\index{Usenet!maps}
\index{UUCP!maps}
\index{maps, Usenet}
A map file mainly consists of a list of sites, listing the sites
each system polls or is polled by.  The system name begins in column
one, and is followed by a comma-separated list of links. The list may
be continued across newlines if the next line begins with a tab.  Each
link consists of the name of the site, followed by a cost given in
brackets. The cost is an arithmetic expression, made up of numbers and
symbolic costs. Lines beginning with a hash sign are
ignored.


As an example, consider \host{moria}, which polls \host{swim.twobirds.com}
twice a day, and \host{bert.sesame.com} once per week. Moreover, the link
to \host{bert} only uses a slow 2400bps modem.  \host{moria}'s would publish
the following maps entry:


\begin{tscreen}
\begin{verbatim}
moria.orcnet.org
        bert.sesame.com(DAILY/2),
        swim.twobirds.com(WEEKLY+LOW)

moria.orcnet.org = moria
\end{verbatim}
\end{tscreen}


The last line would make it known under its UUCP name, too.  Note that
it must be \keyword{DAILY/2}, because calling twice a day actually
halves the cost for this link.


Using the information from such map files, \prog{pathalias} is able to
calculate optimal routes to any destination site listed in the paths
file, and produce a pathalias database from this which can then be used
for routing to these sites.


\index{pathalias@\prog{pathalias}|(}
\prog{pathalias} provides a couple of other features like site-hiding
(i.e. making sites accessible only through a gateway) etc. See the
manual page for \prog{pathalias} for details, as well as a complete list
of link costs.


Comments in the map file generally contain additional information on
the sites described in it. There is a rigid format in which to specify
this, so that it can be retrieved from the maps.  For instance, a
program called \prog{uuwho} uses a database created from the map files
to display this information in a nicely formatted way.


When you register your site with an organization that distributes map files
to its members, you generally have to fill out such a map entry.


Below is a sample map entry (in fact, it's the one for my site):

\begin{tscreen}
\begin{verbatim}
#N      monad, monad.swb.de, monad.swb.sub.org
#S      AT 486DX50; Linux 0.99
#O      private
#C      Olaf Kirch
#E      okir@monad.swb.de
#P      Kattreinstr. 38, D-64295 Darmstadt, FRG
#L      49 52 03 N / 08 38 40 E
#U      brewhq
#W      okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
#
monad   brewhq(DAILY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org
\end{verbatim}
\end{tscreen}


The white space after the first two characters is a TAB.  The meaning of
most of the fields is pretty obvious; you will receive a detailed
description from whichever domain you register with.  The \keyword{L}
field is the most fun to find out: it gives your geographical position
in latitude/longitude and is used to draw the postscript maps that show
all sites for each country, as well as world-wide.\footnote{
 They are posted regularly in \ngrp{news.lists.ps-maps}. Beware. They're
 HUGE.
}

\index{mail!paths file@\file{paths} file|)}
\index{pathalias@\prog{pathalias}|)}
\index{paths file@\file{paths} file|)}

% \section{Message Grading}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% % Message grades in UUCP and on the Internet                    %
% % The meaning of the precedence field.                          %
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{mail.grades}
% To distinguish between important and less important mail, it is
% possible to assign a \emph{grade} to the message. The mail
% transport software may (or may not) evaluate this information,
% and probably use different transports depending on its value. For example,
% very urgent mail might be forwarded immediately, while ordinary
% mail is queued until the next regular contact is established. Also,
% treatment in case of an error may vary: normally, an undeliverable
% message will ``bounce'' and be returned to the sender in its entirety.
% Junk mail, on the other hand, could be thrown away without notice.
% 
% 
% Normally, the message grade is a special token extracted from 
% the \mhdr{Precedence:} header field.
% If it doesn't exist, or contains an unknown token, the mailer will
% assume a default grade.
% 
% 
% The tokens most widely used (because \prog{sendmail} understands them)
% are, in decreasing order: \keyword{special-delivery}, \keyword{first-class},
% and \keyword{junk}. Other mailers, like \prog{smail}, add more tokens, and
% even allow you define your own set of tokens. It is also up to
% the administrator's whim what treatment she assigns to these
% tokens. She may even decide to give all of them equal precedence.
% For \prog{smail}, this will be explained in section~\ref{smail.grades}
% in chapter~\ref{smail}.




\section{Configuring \prog{elm}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.elm}
\index{configuring!elm@\prog{elm}|(}
\index{elm@\prog{elm}|(}

\prog{elm} stands for ``electronic mail'' and is one of the more reasonably
named \unix{} tools. It provides a full-screen interface with a good help
feature. We won't discuss here how to use \prog{elm}, but only dwell on its
configuration options.


Theoretically, you can run \prog{elm} unconfigured, and everything works
well~--- if you are lucky. But there are a few options that must be set,
although only required on occasions.


When it starts, \prog{elm} reads a set of configuration variables from the
\file{elm.rc} file in \elmlib. Then, it will attempt to read the file
\file{.elm/elmrc} in your home directory. You don't usually write this file
yourself. It is created when you choose ``save options'' from \prog{elm}'s
options menu.


The set of options for the private \file{elmrc} file is also available
in the global \file{elm.rc} file. Most settings in your private
\file{elmrc} file override those of the global file.


\subsection{Global \prog{elm} Options}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.elm.global}

In the global \file{elm.rc} file, you must set the options that pertain
to your host's name. For example, at the Virtual Brewery, the file
for \host{vlager} would contain the following:


\begin{tscreen}
\begin{verbatim}
#
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Fully qualified domain name
hostfullname = vlager.vbrew.com
\end{verbatim}
\end{tscreen}


These options set \prog{elm}'s idea of the local hostname. Although this
information is rarely used, you should set these options nevertheless.
Note that these options only take effect when giving them in the global
configuration file; when found in your private \file{elmrc}, they will
be ignored.


\subsection{National Character Sets}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.elm.charsets}
\index{elm@\prog{elm}!national character sets}
\index{internationalization for \prog{elm}}
\index{national character sets in \prog{elm}}
\index{character set in \prog{elm}}
\index{ISO-8859-1}
\index{Latin-1 character set}

Recently, there have been proposals to amend the RFC~822 standard to
support various types of messages, such as plain text, binary data,
Postscript files, etc. The set of standards and RFCs covering these
aspects are commonly referred to as MIME, or Multipurpose Internet Mail
Extensions.  Among other things, this also lets the recipient know if a
character set other than standard ASCII has been used when writing the
message, for example using French accents, or German umlauts.  This is
supported by \prog{elm} to some extent.


The character set used by \linux{} internally to represent characters is
usually referred to as ISO-8859-1, which is the name of the standard it
conforms to. It is also known as Latin-1.  Any message using characters
from this character set should have the following line in its header:


\begin{tscreen}
Content-Type: text/plain; charset=iso-8859-1
\end{tscreen}


The receiving system should recognize this field and take appropriate
measures when displaying the message. The default for
\keyword{text/plain} messages is a \keyword{charset} value of
\keyword{us-ascii}.


To be able to display messages with character sets other than ASCII,
\prog{elm} must know how to print these characters. By default, when
\prog{elm} receives a message with a \keyword{charset} field other than
\keyword{us-ascii} (or a content type other than \keyword{text/plain},
for that matter), it tries to display the message using a command called
\prog{metamail}. Messages that require \prog{metamail} to be displayed
are shown with an `\term{M}' in the very first column in the overview
screen.


\index{metamail@\prog{metamail}}
Since \linux{}' native character set is ISO-8859-1, calling
\prog{metamail} is not necessary to display messages using this
character set. If \prog{elm} is told that the display understands
ISO-8859-1, it will not use \prog{metamail} but will display the message
directly instead. This can be done by setting the following option in
the global \file{elm.rc}:


\begin{tscreen}
displaycharset = iso-8859-1
\end{tscreen}


Note that you should set this options even when you are never going to
send or receive any messages that actually contain characters other than
ASCII. This is because people who do send such messages usually
configure their mailer to put the proper \mhdr{Content-Type:} field into
the mail header by default, whether or not they are sending ASCII-only
messages.


However, setting this option in \file{elm.rc} is not enough.  The
problem is that when displaying the message with its builtin pager,
\prog{elm} calls a library function for each character to determine
whether it is printable or not. By default, this function will only
recognize ASCII characters as printable, and display all other
characters as ``\term{\car ?}''.  You may overcome this by setting the
environment variable \keyword{LC\_CTYPE} to \keyword{ISO-8859-1}, which
tells the library to accept Latin-1 characters as printable. Support for
this and other features is available since \file{libc-4.5.8}.




When sending messages that contain special characters from ISO-8859-1,
you should make sure to set two more variables in the \file{elm.rc}
file:


\begin{tscreen}
charset = iso-8859-1	\\
textencoding = 8bit
\end{tscreen}


This makes \prog{elm} report the character set as ISO-8859-1 in the mail
header, and send it as an 8 bit value (the default is to strip all
characters to 7 bit).


Of course, any of these options can also be set in the private
\file{elmrc} file instead of the global one.


\index{elm@\prog{elm}|)}
\index{configuring!elm@\prog{elm}|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                             %%
%%              E N D   O F   C H A P T E R                    %%
%%                                                             %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
